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Abstract 

A  protection  profile  for  high-robustness  separation  ker¬ 
nels  has  recently  been  validated  and  several  implementa¬ 
tions  are  under  development.  However,  medium-robustness 
separation  kernel  development  efforts  have  no  protection 
profile,  although  the  US  Government  has  published  guid¬ 
ance  for  authoring  such  a  profile. 

As  a  step  toward  a  protection  profile,  a  set  of  security 
requirements  for  medium-robustness  separation  kernels  is 
proposed.  These  requirements  result  from  an  informal,  yet 
principled,  approach.  By  bracketing  the  problem  with  ap¬ 
propriate  reference  points  and  elaborating  a  method  for  in¬ 
terpolating  the  requirements  both  a  measure  of  uniformity 
and  a  basis  for  further  discussion  are  ach  ieved.  Our  refer¬ 
ence  points  include  the  high  robustness  protection  profile, 
the  existing  medium  robustness  consistency  instruction,  and 
our  familiarity  with  the  nuances  of  separation  kernels. 

This  practitioner-oriented  study  is  intended  to  advance 
the  prevailing  practices  for  commercial  software  develop¬ 
ment,  which  presently  falls  far  short  of  the  rigor  needed 
for  either  high-robustness  or  medium-robustness  systems. 
These  requirements  represent  an  incremental  improvement 
in  the  pursuit  of  secure  software  —  and  is  intended  to  be  a 
step  forward  on  the  road  to  higher  assurance. 


1  Introduction 

The  separation  kernel  [Rus81]  has  emerged  as  a  promis¬ 
ing  foundation  for  the  construction  of  highly  secure  systems 
[VBC+05],  In  such  applications  a  separation  kernel  must 
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exhibit  high  robustness  in  the  face  of  attacks  by  resourceful 
adversaries  against  high-value  resources  under  its  control. 

Robustness 

The  Common  Criteria  addresses  only  functionality 
and  assurance,  not  robustness.  The  U.S.  Department 
of  Defense  defines  three  level  of  robustness:  high, 
medium  and  basic.  In  this  context  robustness  is  “a 
characterization  of  the  strength  of  a  security  func¬ 
tion,  mechanism,  service  or  solution,  and  the  assur¬ 
ance  (or  confidence)  that  it  is  implemented  and  func¬ 
tioning  correctly.”  [DOD03]  The  robustness  of  a 
TOE  represents  the  TOE’s  ability  to  mitigate  security 
threats  in  its  operational  environment.  High  robust¬ 
ness  requires  the  security  mechanisms  to  “provide 
the  most  stringent  protection  and  rigorous  security 
countermeasures”  whereas  medium  robustness  im¬ 
poses  requirements  for  “layering  of  addtitional  safe¬ 
guards  above  good  commercial  practices.”  [DOD03] 
Best  commerical  practices  are  considered  as  basic 
robustness. 


The  Separation  Kernel  Protection  Profile  (SKPP) 
[SKP07]  provides  a  set  of  security  functional  require¬ 
ments  (SFRs)  and  security  assurance  requirements  (SARs) 
for  separation  kernels  that  will  be  employed  in  environ¬ 
ments  requiring  high  robustness.  It  admits  implementa¬ 
tions  ranging  from  statically-configured  partitioning  kernels 
with  coarse-grained  information  flow  control  enforcement 
through  dynamically-configured  kernels  with  a  richer  set  of 
exported  resources  and  corresponding  fine-grained  informa¬ 
tion  flow  control  policy  enforcement  [LIN06]. 


Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 
VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  OMB  control  number. 
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Not  every  environment,  however,  requires  such  a  high 
degree  of  robustness,  since  physical  access  constraints  may 
guarantee  a  level  of  trustworthiness  of  individuals  having 
access  to  the  system.  In  such  applications  a  medium¬ 
robustness  separation  kernel  (MR  SK)  may  suffice.  Never¬ 
theless,  the  prospect  of  using  a  common  set  of  components 
and  approaches  to  security  engineering  problems  provides 
motivation  for  the  existence  of  separation  kernels  that  are 
largely  feature-comparable  to  their  high-robustness  coun¬ 
terparts,  but  which  are  required  to  exhibit  only  medium  ro¬ 
bustness. 

The  U.S.  Government  has  recognized  a  need  for  such  a 
class  of  separation  kernels,  as  evidenced  by  at  least  two  de¬ 
velopments:  the  publication  by  NS  A  of  guidence  for  the 
application  of  both  high-  and  medium-robustness  separa¬ 
tion  kernels  [NSA05b],  and  the  determination  by  some  DoD 
programs  of  the  adequacy  of  a  medium-robustness  separa¬ 
tion  kernel  for  certain  applications. 

A  proper  protection  profile  (PP)  for  medium-robustness 
separation  kernels  would  present  both  SFRs  and  SARs  de¬ 
rived  by  a  methodical  analysis  of  the  security  environment 
and  security  objectives  following  the  model  of  the  Common 
Criteria  [CC205], 

This  study  proposes  a  set  of  requirements  for  medium¬ 
robustness  separation  kernels.  Though  informally  derived, 
in  contrast  with  the  detailed  analysis  and  justification  re¬ 
quired  in  a  PP,  these  requirements  are  based  on  an  interpo¬ 
lation  of  reliable  sources  informed  by  our  familiarity  with 
separation  kernel  requirements.  We  hope  that  providing  this 
study  can  facilitate  and  provide  consistency  among  ongo¬ 
ing  development  efforts,  as  well  as  offer  a  stepping  stone 
to  a  PP.  In  addition,  the  separation  kernel  is  one  of  many 
potential  targets  of  evaluation  that  could  exist  in  both  high¬ 
robustness  and  medium-robustness  implementations,  hence 
a  viable  repeatable  method  for  “requirements  interpolation” 
could  provide  wider  benefit. 

2  Methodology 

We  wanted  to  study  the  security  requirements  for  separa¬ 
tion  kernels  suitable  for  deployment  in  environments  requir¬ 
ing  medium  robustness,  without  taking  on  the  considerable 
commitment  of  developing  a  protection  profile. 

We  hypothesized  that,  given  knowledge  of  the  validated 
high-robustness  SKPP,  of  medium-robustness  consistency 
guidance,  and  of  the  nuances  of  separation  kernels,  then  it 
would  be  possible  to  arrive  systematically  at  a  good  approx¬ 
imation  of  the  requirements  for  a  medium-robustness  sepa¬ 
ration  kernel  without  incurring  the  expense  of  PP  develop¬ 
ment. 

The  method  should  establish  the  reference  points  and  the 
reasoning  to  be  applied  to  allow  interpolation  of  each  re¬ 
quirement  for  medium  robustness.  Determining  this  a  pri¬ 


ori  would  reduce  the  variance  of  discretion  applied  among 
requirements.  If  a  result  appeared  unsatisfactory,  it  could  be 
analyzed  to  determine  why,  and  then  the  method  tuned  and 
reapplied. 

A  strategic  choice  was  to  use  the  rationale  provided  in 
the  SKPP  as  a  key  reference,  because  it  is  the  most  detailed 
written  repository  of  knowledge  concerning  what  makes 
a  separation  kernel  unique.  By  applying  rationale  similar 
to  that  used  in  the  SKPP,  and  making  only  the  necessary 
changes  while  adjusting  for  the  reduced  assurance  level,  it  is 
possible  to  have  reasonable  confidence  that  this  informally 
derived  set  of  requirements  is  a  close  approximation  to  that 
obtainable  by  a  more  rigorous  analysis. 

The  methodology  involved  the  following  steps: 

1.  Collect  relevant  and  documentation  sources  to  con¬ 
sider  for  medium  robustness  guidance  and,  based  on 
their  applicability  to  this  study,  choose  the  final  set  to 
be  relied  upon. 

2.  Determine  whether  any  security  functional  require¬ 
ments  in  the  SKPP  could  be  dispensed  with  outright, 
or  weakened,  in  a  medium-robustness  separation  ker¬ 
nel. 

3.  Decide  and  finalize  the  functional  requirements  for  a 
medium-robustness  separation  kernel,  giving  prefer¬ 
ence  to  functional  interchangeability  with  the  high¬ 
robustness  separation  kernel 

4.  Consider,  in  turn,  each  assurance  family  identified  in 
the  SKPP. 

5.  Identify  an  appropriate  assurance  component  for  each 
family  based  on  the  decision  process  detailed  below  in 
the  Security  Assurance  Requirements  section. 

The  functional  and  assurance  requirements  will  be  enumer¬ 
ated  in  later  sections.  The  remainder  of  this  section  dis¬ 
cusses  the  selection  of  sources  used  for  the  activity. 

The  assurance/robustness  guidance  documents  identified 
for  initial  consideration  were: 

1.  Separation  Kernel  Protection  Profile  (SKPP)  [SKP07] 

2.  Common  Criteria  (CC)  [CC205] 

3.  US  Government  Protection  Profile  for  Multilevel  Op¬ 
erating  Systems  in  Environments  Requiring  Medium 
Robustness  (MLOSPP)[MLO07] 

4.  IA  Guidance  for  Systems  Based  on  a  Security  Real- 
Time  OS  (IAG)  [NSA05b] 

5.  Medium  Robustness  Consistency  Instruction  Manual 
(MR-CIM)[NSA05a] 


The  IAG  recommends  the  use  of  “a  Medium  Robustness 
SRTOS1  or  a  High  Robustness  SRTOS,  depending  on  the 
scenario  and  a  variety  of  factors.”  Further,  it  states  that  a  PP 
should  comply  with  the  MR-CIM  and,  as  a  starting  point, 
use  the  security  requirements  from  the  SKPP  and  the  assur¬ 
ance  requirements  from  the  MLOSPP. 

A  multilevel  operating  system  is  very  different  from  a 
separation  kernel.  The  MLOSPP  describes  a  full-featured 
operating  system  with  label-based  security  policy  enforce¬ 
ment.  The  SKPP  describes  a  minimal  operating  system  that 
lacks  not  only  label-based  security  but  most  of  the  services 
required  of  an  OS  meeting  the  MLOSPP.  A  separation  ker¬ 
nel  could  be  used  as  the  foundation  for  implementing  the 
features  of  a  multilevel  operating  system,  and  must  have  at 
least  the  strength  of  function  of  any  mechanism  it  is  used 
to  support.  A  version  of  the  MLOSPP  had  been  consulted 
as  the  SKPP  was  being  developed,  and  its  influence  has  al¬ 
ready  been  distilled  and  filtered  through  the  SKPP  refine¬ 
ment  process.  Given  the  other  more  appropriate  resources 
at  our  disposal  we  chose  not  to  directly  rely  further  upon  the 
MLOSPP  for  the  present  exercise. 

The  IAG-provided  guidance  regarding  medium¬ 
robustness  separation  kernel  requirements  is  indirect:  it 
merely  cites  other  documents  as  sources  for  guidance.  The 
documents  cited  are  among  those  we  considered,  and  the 
approach  suggested  by  the  IAG  is  very  similar  to  the  one 
described  here,  with  the  exception  of  the  exclusion  of  the 
MLOSPP. 

3  Security  Functional  Requirements 

The  SKPP  describes  a  broad  class  of  separation  kernels. 
It  is  assumed  that  a  medium-robustness  separation  kernel 
would  be  employed  in  a  fashion  architecturally  similar  to 
its  high-robustness  counterpart  [NSA05b],  though  in  a  more 
sheltered  environment.  A  medium-robustness  separation 
kernel  protection  profile  should  reflect  this  assumption,  as 
it  engenders  a  commonality  of  components  and  approaches 
across  the  assurance  spectrum,  fostering  cost  savings  and 
adaptability  to  changing  environmental  requirements. 

For  situations  in  which  a  SK  security  architecture  is 
developed  for  an  environment  requiring  medium  robust¬ 
ness  and  then  is  later  applied  to  an  environment  requiring 
high  robustness,  it  would  be  advantageous  if  the  medium¬ 
robustness  separation  kernel  could  be  replaced  by  a  high¬ 
robustness  separation  kernel  with  little  or  no  architectural 
change.  Therefore,  it  is  proposed  that  a  medium-robustness 
separation  kernel  have  SFRs  not  substantially  different  from 
a  high-robustness  separation  kernel,  with  the  minor  excep- 

1  The  IAG  defines  an  SRTOS  as  “a  separation  kernel-based  Real-Time 
Operating  System  that  has  undergone  an  appropriate  security  evaluation." 
In  this  study,  such  an  operating  system  is  generically  referred  to  as  a  "sep¬ 
aration  kernel.” 


tions  noted  in  the  following  section.  Thus,  the  greatest  dif¬ 
ference  between  a  high-robustness  separation  kernel  and  a 
medium-robustness  separation  kernel  would  be  the  SARs. 

4  Security  Assurance  Requirements 

The  security  assurance  requirements  for  evaluation  of 
a  medium-robustness  separation  kernel  should  be  less  de¬ 
manding  than  those  of  the  high-robustness  SKPR  Table  1 
summarizes  the  proposed  SARs  using  SKPP  nomenclature, 
providing  information  from  the  source  documents  for  com¬ 
parison  and  a  reference  to  the  discussion  in  the  following 
sections.  According  to  convention,  component  numbers  not 
in  parentheses  (e.g.,  “3”)  indicate  an  unmodified  component 
from  the  Common  Criteria  catalog  of  SARs,  while  those 
in  parentheses  (e.g.,  “(3)”)  indicate  an  explicit  requirement. 
Numbering  of  explicit  assurance  components  can  be  mis¬ 
leading.  “(1)”  is  not  necessarily  a  less  demanding  require¬ 
ment  than  that  represented  by  a  “3,”  or  that  represented  by 
an  explicit  requirement  “(2)”  in  another  document.  Some 
authors  start  numbering  explicit  requirements  within  a  fam¬ 
ily  starting  at  1 ,  while  others  use  the  number  of  the  CC  com¬ 
ponent  most  closely  matching  the  explicit  component.  The 
“  x’  ”  and  “  x*  ”  designations  represent  a  decrease  in  the 
component  leveling  defined  by  the  SKPP  and  MR  CIM,  re¬ 
spectively.  The  rationale  for  these  changes  is  provided  in  the 
subsections  associated  with  the  corresponding  families.  The 
EAL  4  and  EAL  6  columns  represent  the  security  assurance 
requirements  in  the  standard  package  for  each  EAL  given 
in  Version  2.3  of  the  Common  Criteria.  The  SKPP  (HR) 
column  gives  the  SARs  from  Version  1.03  of  the  SKPP. 
The  MR  CIM  column  gives  the  generic  medium  robustness 
requirements  recommended  by  the  Consistency  Instruction 
Manual. 

Though  many  of  the  MR  SK  requirements  may  corre¬ 
spond  to  those  of  MR  CIM,  a  wholesale  adoption  of  the  MR 
CIM  requirements  is  not  appropriate  for  a  separation  kernel. 
Special  considerations  arise  from  the  nature  of  a  separation 
kernel  TOE  qua  separation  kernel,  and  these  considerations 
apply  generally  to  a  MR  SK  as  well  as  to  one  of  high  robust¬ 
ness,  though  the  degree  to  which  they  may  apply  must  be 
determined.  These  considerations  played  a  role  in  defining 
the  requirements  presented  here  for  a  medium  robustness 
separation  kernel. 

In  some  cases  the  medium-robustness  requirement  is  de¬ 
rived  in  a  similar  manner  to  that  of  the  corresponding  SKPP 
requirement,  though  placed  lower  in  the  assurance  hierar¬ 
chy.  As  an  example,  consider  the  Functional  Specifica¬ 
tion  (ADV  I  SP)  family.  The  CC  EAL  6  package  spec¬ 
ifies  component  “3”  (ADV_FSP.3).  The  SKPP  specifies 
ADV_FSP_EXP4,  a  tailored  version  of  component  ”4,” 
while  our  medium-robustness  requirement  replaces  the  CC 
EAL  4  component  “2”  with  a  tailored  version  of  component 


Table  1.  Security  Assurance  Requirements 


Assurance 

Class 

Assurance 

Family 

EAL6 

CCv2.3 

SKPP 

(HR) 

EAL4 

CCv2.3 

MR 

CIM 

MR 

SK 

MR  SK 
Comment 

See 

Section 

Config  Mgmt 

ACM  _  AUT 

2 

2 

1 

1 

1 

MR  CIM 

§5.2 

ACM.CAP 

5 

5 

4 

4 

4 

MR  CIM 

ACM.SCP 

3 

3 

2 

2 

2 

MR  CIM 

Delivery  and 
Operation 

ADO_DEL_EXP 

2 

(2) 

2 

2 

(2) 

NIST  crypto 

§5.3.1 

ADOJGS 

1 

1 

1 

1 

1 

§5.3.2 

Development 

ADV_ARC_EXP 

(1) 

(it 

(1) 

MR  adjusted 

§5.4.1 

ADV_CTD_EXP 

(1) 

(1) 

SKPP 

§5.4.2 

ADV_FSP_EXP 

3 

(4) 

2 

1 

(3) 

semiformal 

§5.4.3 

ADV_HLD_EXP 

4 

(4) 

2 

1 

(4) 

SKPP 

§5.4.4 

ADV_IMP_EXP 

3 

(3) 

1 

2 

2 

MR  CIM 

§5.4.5 

ADVJNI_EXP 

(1) 

at 

SKPP 

§5.4.6 

ADVJNT_EXP 

2 

(3) 

(it 

at 

MR  CIM 

§5.4.7 

ADV_LLD_EXP 

2 

(2) 

1 

(it 

at 

MR  CIM 

§5.4.8 

ADV_LTD_EXP 

(1) 

at 

SKPP 

§5.4.9 

ADV  _RCR_EXP 

2 

3 

1 

1 

2 

semiformal 

§5.4.10 

ADV_SPM_EXP 

3 

3 

1 

1 

3 

formal 

§5.4.11 

Guidance 

Documents 

AGD_ADM_EXP 

1 

(i) 

1 

1 

at 

SKPP 

§53 

AGDJJSR 

1 

1 

1 

1 

1 

Life  Cycle 
Support 

ALC-DVS 

2 

2 

1 

1 

1 

MR  CIM 

§5.6 

ALC_FLR 

3 

2 

2 

MR  CIM 

ALC_LCD 

2 

2 

1 

1 

1 

MR  CIM 

ALC.TAT 

3 

3 

1 

1 

2 

+  impl  stds 

Assur.  Maint 

AMA_AMP_EXP 

a) 

at 

SKPP 

§5.7 

Platform 

Assurance 

APT_PDF_EXP 

a) 

(!’) 

mod’d  SKPP 

§5.8.1 

APT_PSP_EXP 

a) 

(!’) 

mod’d  SKPP 

§5.8.2 

APT_PCT_EXP 

(i) 

ci’) 

mod’d  SKPP 

§5.8.3 

APT_PST_EXP 

a) 

(!’) 

mod’d  SKPP 

§5.8.4 

APT_PVA_EXP 

(a 

(!’) 

mod’d  SKPP 

§5.8.5 

Tests 

ATE.COV 

3 

3 

2 

2 

2 

MR  CIM 

§5.9 

ATE.DPT 

2 

3 

1 

2 

2 

MR  CIM 

ATE_FUN 

2 

2 

1 

1 

1 

MR  CIM 

ATEJND 

2 

3 

2 

2 

2 

MR  CIM 

Vulnerability 

Assessment 

AVA_CCA_EXP 

2 

(2) 

2 

a*) 
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AVA_VLA_EXP 

4 
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2 

3 

3 
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“3.”  In  a  very  few  cases,  the  specified  medium-robustness 
requirement  is  identical  to  that  specified  in  the  SKPP.  Spe¬ 
cific  considerations  influencing  the  determination  of  appro¬ 
priate  components  are  discussed  in  the  following  section. 

5  Discussion  of  the  Assurance  Requirements 

The  following  subsections  describe  the  rationale  used  to 
derive  the  MR  SK  assurance  requirements  for  each  assur¬ 
ance  class.  In  cases  where  explicit  requirements  from  the 
SKPP  are  applicable  to  the  MR  SK,  excerpts  from  the  SKPP 
rationale  for  those  explicit  requirements  are  included. 

5.1  A  Note  on  Semiformal  Style 

It  was  necessary  to  define  an  appropriate  guideline  for 
“semiformal”  for  this  study  since  the  range  of  what  can 
qualify  as  semiformal  is  very  broad.  Informal  is  defined 
as  natural  language,  formal  is  defined  as  a  restricted  syn¬ 
tax  language  with  formal  semantics,  and  semiformal  is  any¬ 
thing  in  between.  This  would  admit  natural  language  with 
paragraph  headings  at  one  extreme  and  formal  specification 
languages  without  a  formal  semantics  at  the  other  extreme. 


To  avoid  ambiguity  there  needs  to  be  a  common  lan¬ 
guage  among  the  designer,  the  implemented  and  the  eval¬ 
uator  such  that  requirements  can  be  interpreted  the  same  by 
all.  At  a  minimum,  for  semiformal  notation  we  recommend 
a  language  with  a  defined  syntax  and  a  well-documented 
informal  semantics  that  can  support  reasonably  unambigu¬ 
ous  compositional  reasoning  required  for  correspondence 
demonstration  of  evaluation  evidences. 

5.2  Configuration  Management 

The  ACM  class  contains  three  families:  CM  Automation 
(AUT),  CM  Capabilities  (CAP),  and  CM  Scope  (SCP).  The 
requirements  in  this  class  are  straightforward.  The  SKPP 
directly  adopts  the  standard  EAL  6  components  for  each 
family  in  the  ACM  class.  The  MR  CIM  similarly  adopts  the 
EAL  4  component.  We  follow  EAL  4  and  the  MR  CIM  by 
requiring  ACM.AUT.  1 ,  ACM.CAP.4  and  ACM_SCP,2. 

5.3  Delivery  and  Operation 

The  critical  nature  of  delivery  is  easily  overlooked,  but 
it  provides  a  prime  opportunity  for  subversion  [Mye80] .  In 
an  environment  where  a  separation  kernel  is  used  to  isolate 


levels  of  sensitive  information,  though  it  is  accessed  only 
by  trustworthy  users,  undetected  subversion  during  delivery 
could  compromise  critical  missions.  Therefore  adoption  of 
the  SKPP  required  components  with  the  modifications  dis¬ 
cussed  below  is  recommended. 

5.3.1  Delivery  (ADO_DEL) 

While  MR  CIM  requires  only  component  ADO_DEL.2  (de¬ 
tection  of  modification  and  of  attempts  to  masquerade  as  the 
developer),  which  is  the  same  for  both  EAL  4  and  EAL  6, 
it  was  determined  for  the  SKPP  that  an  explicit  requirement 
was  needed.  The  use  of  NIST-approved  cryptographic  sig¬ 
nature  algorithms  and  keyed-hash  message  authentication 
functions  to  support  trusted  delivery  of  the  TOE  was  re¬ 
quired.  Starting  with  the  base  CC  component  ADO_DEL.2, 
elements  were  added  to  require  the  developer  to  provide 
documentation  for  trusted  delivery  and  to  demonstrate  the 
use  of  NIST- validated  cryptographic  mechanisms  in  support 
of  their  trusted  delivery  processes,  thus  providing  additional 
assurance  against  undetected  tampering. 

The  following  application  note  is  suggested  for  the 
medium-robustness  requirements:  though  it  may  be  pos¬ 
sible  to  meet  the  delivery  requirements  without  the  use 
of  cryptography,  if  technical  measures  are  used  to  sat¬ 
isfy  ADO  DEL  EXP.  1  and  those  measures  include  cryp¬ 
tographic  mechanisms,  then  such  mechanisms  should  im¬ 
plement  NIST-approved  algorithms,  though  certification  is 
not  required.  The  additional  evaluator  action  to  deter¬ 
mine  the  sufficiency  of  the  strength  of  mechanism  for 
the  trusted  delivery  mechanism  required  by  the  SKPP  in 
ADO_DEL_EXP.2.2E  has  been  dropped. 

5.3.2  Installation,  Generation  and  Start-Up 
(ADOJGS) 

The  Common  Criteria  only  defines  two  components  for  this 
family,  ADOJGS.  1  and  ADOJGS. 2;  however,  all  of  the 
CC  standard  EAL  packages,  as  well  as  the  SKPP  and  the 
MR  CIM  adopt  ADOJGS.  1.  Likewise,  for  medium  robust¬ 
ness,  only  ADOJGS.  1  has  been  included. 

5.4  Development 

The  ADV  class  contains  the  assurance  families:  Archi¬ 
tectural  Design  (ARC),  Configuration  Tool  Design  (CTD), 
Functional  Specification  (FSP),  High-Level  Design  (HLD), 
Implementation  Representation  (IMP),  Trusted  Initializa¬ 
tion  (INI),  TSF  Internals  (INT),  Low-Level  Design  (LLD), 
Load  Tool  Design  (LTD),  Representation  Correspondence 
(RCR),  and  Security  Policy  Modeling  (SPM)  as  described 
in  the  following  subsections. 


5.4.1  Architectural  Design  (ADV_ARC) 

This  assurance  family  is  not  present  in  the  Common  Crite¬ 
ria  Version  2.3  but  it  has  been  explicitly  included  in  the  MR 
CIM,  in  other  medium-robustness  protection  profiles,  and 
in  the  SKPP.  In  the  case  of  the  SKPP,  it  was  recognized  that 
a  new  assurance  criterion  was  necessary  to  require  assur¬ 
ance  evidence  specific  to  the  TSF  architecture  and  its  abil¬ 
ity  to  protect  itself,  to  support  the  principle  of  least  privi¬ 
lege  for  the  purpose  of  damage  limitation,  and  to  prevent 
TSF-intemal  denial  of  service  by  executing  in  a  predictable 
manner.  ADV_ARCJ2XP.l  was  created  to  address  these  re¬ 
quirements.  It  is  worth  noting  that  several  assurance  ele¬ 
ments  in  ADV_ARC_EXP.  1  are  related  to  SFRs.  Thus  the 
testable  desired  behavior  of  the  TOE  in  terms  of  functional 
requirements  is  precisely  defined  as  are  the  assurances  re¬ 
quired  to  determine  that  the  desired  behavior  is  achieved  by 
the  implementation. 

For  medium  robustness,  a  similar  explicit  ADV_ARC 
component  should  be  defined  and  the  assurance  levied 
must  be  commensurate  with  the  degree  of  scope,  depth 
and  rigor  provided  by  the  functional  specification,  high- 
level  design  and  the  TSF  internals  description.  As  stated 
in  the  application  note  for  ADV_ARCJ2XP.l  in  the  SKPP, 
“the  architecture  design  required  by  this  component  is  at 
the  level  of  the  functional  specification  and  high-level  de¬ 
sign  documentation.  The  TSF  internals  description  re¬ 
quired  by  ADVJNT_EXP3  component  is  at  the  level  of 
TSF  module  documentation.”  This  reasoning  leads  to 
medium  robustness  for  the  adjusted  rigor  of  the  func¬ 
tional  specification,  high-level  design,  and  internals  de¬ 
scription.  These  adjustments  are  subsumed  by  the  wording 
of  A DV_A RC  EXP.  1 ,2C,  which  states  that  the  architectural 
design  “shall  be  at  a  level  of  detail  commensurate  with  the 
description  of  the  SFR-enforcing  abstractions  described  in 
the  TOE  high-level  design  documentation.” 

5.4.2  Configuration  Tool  Design  (ADV-CTD) 

This  assurance  family  is  not  defined  in  the  Common  Criteria 
but  explicitly  added  by  the  SKPP  to  address  concerns  about 
the  validity  of  the  configuration  vector(s)  that  the  separation 
kernel  relies  on  to  establish  the  initial  secure  state  and  to 
enforce  the  partition  flow  policy.  The  configuration  vector 
has  a  direct  bearing  on  the  ability  to  produce  an  inductive 
proof  of  the  basic  security  theorem2. 

The  configuration  vector  is  generated  and  validated  by  a 
configuration  tool.  Because  the  configuration  tool  is  part  of 
the  TOE  but  not  part  of  the  TSF,  it  is  not  subject  to  most 
of  the  ADV  documentation  SARs.  The  absence  of  a  CC  as- 

2The  Basic  Security  Theorem  establishes  that  the  system  never  enters 
an  unsecure  state.  A  proof  of  the  BST  typically  takes  the  form  of  an  induc¬ 
tion  on  states,  comprising  a  secure  initial  state(s)  and  security  invariant¬ 
preserving  transitions  on  states. 


surance  family  that  addresses  the  assurances  for  generating 
the  configuration  vector  and  for  establishing  the  correctness 
of  the  configuration  vector  drives  the  need  for  an  explicit 
requirement. 

This  explicit  requirement  compels  the  developer  to  pro¬ 
vide  a  design  that  can  be  evaluated  to  assure  that  the  con¬ 
figuration  tool  is  trustworthy  to  perform  its  functions.  The 
wording  of  the  explicit  requirement  specifies  the  level  of 
rigor  as  “informal  style  at  a  level  of  abstraction  and  detail 
required  in  the  TOE  high-level  design  document.” 

5.4.3  Functional  Specification  (ADV  J’SP) 

The  MR  CIM  has  an  explicit  component 
ADVJFSP  (EXP).l  for  FSP.  Inspection  of  the  SKPP 
ADV_FSP_EXP.4  reveals  that  its  explicit  differences  have 
been  influenced  by  the  MR  CIM  ADV_FSP_(EXP).l. 
The  additional  requirements,  as  described  in  the  SKPP 
rationale,  are  necessary  to  provide  the  evaluator  sufficient 
information  to  assess  the  intended  use  and  behavior  of 
each  kernel  external  interface.  Before  adding  these  explicit 
differences,  the  SKPP  escalated  the  component  from 
ADV_FSP.3  to  ADV_FSP4,  which  differs  solely  by  a 
change  from  semiformal  to  formal  style.  This  permits  the 
correspondence  demonstration  between  the  security  policy 
model  and  the  functional  specification  to  be  formal  for  a 
high-robustness  separation  kernel. 

For  the  medium-robustness  separation  kernel  we  employ 
a  similar  strategy.  We  escalate  ADV_FSP.2  from  CC  EAL 
4  to  ADV_FSP.3,  which  changes  the  functional  specifica¬ 
tion  from  informal  to  semiformal  style,  and  then  add  the 
additional  requirements  levied  by  the  SKPP.  The  change 
to  semiformal  style  works  hand-in-hand  with  the  formal 
ADV_SPM  requirement  to  permit  a  meaningful  semiformal 
correspondence  demonstration. 

5.4.4  High-Level  Design  (ADV_HLD) 

The  SKPP  and  the  MR  CIM  both  specify  explicit  re¬ 
quirements  for  HLD.  That  of  the  SKPP  is  based  on  CC 
ADV_HLD.4  but  is  tailored  to  take  into  account  the  struc¬ 
ture  of  the  separation  kernel  and  has  fewer  elements 
than  ADV  HLD. 4.  Following  this  pattern,  the  medium¬ 
robustness  requirement  would  be  ADV  HLD  EXP.2,  a  sim¬ 
ilarly  tailored  version  of  ADV_HLD.2. 

The  SKPP  ADV_HLD_EXP4  calls  for  a  semiformal 
style  supported  by  informal  explanatory  text  for  the  TSF, 
and  an  informal  style  for  the  non-TSF.  It  is  the  difference  in 
rigor  between  TSF  and  non-TSF  that  differentiates  the  re¬ 
quirements  for  the  high-robustness  SK  from  that  of  a  “best 
practice”  high-level  design  with  typical  good  software  en¬ 
gineering  discipline  and  documentation.  We  believe  that 
reducing  the  rigor  requirement  to  informal  is  acceptable  for 
medium  robustness.  Note  that  it  may  be  more  difficult  to 


distinguish  and  separate  the  TSF  from  the  non-TSF  if  the 
design  was  created  without  having  such  differentiation  as 
an  objective. 

5.4.5  Implementation  Representation  (ADV_IMP) 

For  medium  robustness  we  follow  the  MR  CIM  by  employ¬ 
ing  ADV  JMP.2. 

5.4.6  Trusted  Initialization  (ADV_INI) 

Trusted  initialization  continues  the  chain  of  assurance  main¬ 
tained  through  distribution  and  configuration  by  other  re¬ 
quirements,  but  there  was  not  an  assurance  family  for  it 
in  the  Common  Criteria.  Trusted  Initialization  was  explic¬ 
itly  added  by  the  SKPP.  Because  the  TOE  must  be  able  to 
initialize  and  establish  a  secure  initial  state  autonomously, 
without  any  intervention  by  authorized  administrators,  as¬ 
surances  are  required  for  trusted  initialization  of  the  TOE 
when  that  initialization  is  accomplished  without  the  aid  of 
authorized  administrators.  The  initialization  function  is  re¬ 
sponsible  for  trusted  initialization  of  the  TOE  which  in¬ 
cludes  establishing  the  execution  environment  for  the  TSF 
and  establishing  the  TSF  in  its  initial  secure  state.  Since  the 
initialization  function  is  part  of  the  TOE  but  not  part  of  the 
TSF,  it  is  not  subject  to  most  of  the  ADV  documentation 
SARs. 

For  a  medium-robustness  separation  kernel  we  adopt  the 
same  requirement  used  in  the  SKPP.  The  ADVJNLEXP.  1 
requirement  is  levied  in  recognition  that  establishment  of 
a  secure  initial  state  is  fundamental  to  a  proof  of  the  basic 
security  theorem.  Although  the  initialization  function  is  not 
part  of  the  TSF,  the  conversion  of  configuration  vectors  into 
the  TSF  data  must  be  shown  to  preserve  the  semantics  of 
the  configuration  data..  This  requirement  provides  a  design 
for  the  initialization  function  to  the  extent  it  is  not  included 
in  the  design  of  the  TSF. 

5.4.7  TSF  Internals  (ADVJNT) 

This  requirement  addresses  the  internal  structure  of  the  TSF. 
The  TSF  Internals  requirement  is  a  CC  component  that  is 
one  of  the  primary  factors  contributing  to  the  conventional 
wisdom  that  pre-existing  products  can  only  be  evaluated  to 
EAL  4  (without  being  redesigned  and  reimplemented).  The 
standard  CC  EAL  4  package  does  not  include  an  ADVJNT 
requirement.  For  medium  robustness  we  follow  the  MR 
CIM  by  employing  ADV  JNT  (EXP)  .1.  This  requirement 
is  substantially  more  specific  than  ADVJNT.  1  in  the  CC 
(the  standard  component  for  EAL  5).  The  software  engi¬ 
neering  discipline  entailed  by  this  explicit  requirement  may 
challenge  pre-existing  implementations  not  developed  with 
this  requirement  in  mind. 


5.4.8  Low-Level  Design  (ADVXLD) 

For  medium  robustness  we  adopt  ADVXLD_(EXP).l  of 
the  MR  CIM.  This  requirement  is  more  specific  than 
ADV_LLD.l  and  is  apparently  intended  to  work  together 
with  ADV  INT  (EXP).  1  to  enforce  more  stringent  software 
engineering  practices.  The  presentation  style  required  is 
still  informal. 

5.4.9  Load  Tool  Design  (  ADV  LI  D) 

Like  the  configuration  tool,  this  assurance  family  is  not 
present  in  the  Common  Criteria  but  is  explicitly  added  by 
the  SKPP 

The  ADV_LTD_EXP  requirement  is  levied  in  recogni¬ 
tion  that  the  load  tool  is  a  crucial  part  of  the  TOE’s  evalua¬ 
tion  because  it  is  part  of  the  chain  that  establishes  the  initial 
state,  thus  having  a  direct  bearing  on  the  ability  to  provide 
an  inductive  proof  of  the  basic  security  theorem.  Through 
the  ADV  class,  essential  assurance  measures  are  applied  to 
security  critical  components  within  the  TOE;  however,  be¬ 
cause  it  is  not  part  of  the  executable  kernel,  these  measures 
would  not  be  applied  to  the  load  tool.  An  explicit  require¬ 
ment  levied  specifically  on  the  load  tool  requires  the  devel¬ 
oper  to  provide  a  load  tool  design  that  can  be  evaluated  for 
assurance  that  it  is  trustworthy  to  perform  its  functions. 

5.4.10  Representation  Correspondence  (ADV_RCR) 

The  SKPP  escalates  the  EAL  6  component  ADV  RCR.2  to 
ADV  RCR.3  because  the  SKPP  requires  formal  FSP  and 
SPM.  The  FSP  and  SPM  proposed  for  medium-robustness 
separation  kernels  by  this  work  are  semiformal  and  formal 
respectively.  We  therefore  escalate  the  medium-robustness 
requirement  to  ADV  RCR.2  over  the  EAL  4  component 
ADVJRCR.l  (also  specified  in  the  MR  CIM). 

5.4.11  Security  Policy  Modeling  (ADV  SPM) 

The  CC  has  an  idiosyncracy  in  the  usage  of  the  ADV_SPM 
class  in  the  standard  EAL  packages,  in  that  the  semiformal 
component  is  not  used  in  any  EAL.  SPM  is  informal  at  EAL 
4  and  formal  at  EAL  5  and  above. 

We  have  chosen  to  utilize  the  CC  ADV_SPM.3  com¬ 
ponent,  a  formal  security  policy  model,  for  the  medium¬ 
robustness  separation  kernel.  In  this  way  a  meaningful 
semiformal  correspondence  demonstration  can  be  done  be¬ 
tween  the  formal  security  policy  model  and  the  semiformal 
functional  specification. 

5.5  Guidance  Documents 

The  Common  Criteria  defines  only  one  component  for 
each  of  the  families  AGD_ADM  and  AGCJUSR.  The  SKPP 


creates  an  explicit  component,  AGD_ADM_EXP.  1  because 
separation  kernel  specific  considerations  result  in  a  number 
of  explicit  requirements  that  must  be  mirrored  in  the  ad¬ 
ministrator  guidance.  For  medium  robustness  we  adopt  the 
same  requirements  as  the  SKPP,  viz.,  AGD_ADM_EXP.  1 
and  AGDJJSR.  I . 

5.6  Life  Cycle  Support 

The  ALC  class  contains  the  families:  Development  Se¬ 
curity  (DVS),  Flaw  Remediation  (FLR),  Life  Cycle  Defini¬ 
tion  (LCD),  and  Techniques  and  Tools  (TAT).  The  Common 
Criteria  does  not  utilize  the  FLR  family  in  any  of  the  EAL 
packages.  The  SKPP  and  the  MR  CIM  both,  however,  in¬ 
clude  a  component  from  the  FLR  family. 

For  medium  robustness  we  follow  the  MR  CIM  for  ALC 
families  DVS,  FLR  and  LCD  by  requiring  ALC_DVS.l, 
ALC  FLR. 2,  and  ALCXCD.l.  For  the  Techniques  and 
Tools  family,  however,  we  believe  that  the  ALC  TAT.  1  com¬ 
ponent  required  by  the  MR  CIM  is  too  weak  for  a  newly 
developed  TOE,  which  a  separation  kernel  is  likely  to  be, 
and  instead  require  ALC_TAT.2. 

The  specific  difference  between  ALC  XXL  1  and 
ALCXAT.2  is  that  the  subset  of  the  implementation  defined 
by  the  ADVJMP  family  (we  have  specified  ADVJMP.2, 
following  the  MR  CIM)  must  comply  with  explicitly  stated 
implementation  standards,  and  that  the  evaluator  must  con¬ 
firm  that  the  standards  have  been  applied.  The  Common 
Criteria  neglects  to  state  where  those  implementation  stan¬ 
dards  are  to  be  defined,  so  we  would  add  an  application 
note  to  suggest  that  the  developer  provide  a  Techniques  and 
Tools  document  that  includes  the  definition  of  the  imple¬ 
mentation  standards  to  be  applied,  as  well  as  the  other  con¬ 
tent  items  required  by  ALCXAT.2. 

5.7  Maintenance  of  Assurance 

For  the  SKPP,  the  explicit  component 
AMAXMPXXP.  1  was  written  to  define  the  require¬ 
ments  for  an  assurance  maintenance  plan. 

While  it  may  be  debatable  whether  the  use  of 
AMAXMPXXP.  1  is  required  only  for  the  high  robustness 
requirement  and  not  for  medium  robustness,  the  benefits  of 
assurance  maintenence  to  the  developer  of  a  TOE  at  any 
robustness  level  should  be  recognized.  The  reality  of  prod¬ 
uct  change  and  the  cost  of  evaluation  should  make  apparent 
the  benefits  of  minimizing  reevaluation  cost.  A  well-written 
Assurance  Maintenance  Plan  (AMP)  effectively  permits  the 
evaluators  to  evaluate  “at  once”  the  TOE  in  all  variations 
that  the  AMP  can  successfully  justify  to  not  require  reeval¬ 
uation.  As  a  practical  matter,  this  should  also  be  a  require¬ 
ment  for  medium  robustness  separation  kernels. 


5.8  Platform  Assurance 

The  MR  CIM  specifies  that  domain  separation  require¬ 
ments  (FPT_SEP)  must  be  included  in  a  medium  robust¬ 
ness  TOE,  and  thus  the  underlying  hardware  mechanisms 
that  the  TOE  depends  on  to  support  its  security  architec¬ 
ture  must  also  be  included  as  part  of  the  TOE.  To  date,  the 
CC  does  not  include  requirements  for  assessing  the  assur¬ 
ance  of  hardware  components  used  to  implement  a  TOE’s 
security  functions.  Since  it  is  difficult  for  TOE  vendors  to 
produce  assurance  evidence  for  hardware  at  the  same  level 
of  detail  that  is  required  for  software,  it  was  necessary  to 
introduce  a  separate  assurance  class  in  the  SKPP  to  pro¬ 
vide  a  framework  for  establishing  the  security  relevance  of 
commercially-available  hardware  based  on  its  interaction 
with  software  through  its  interfaces.  As  noted  in  the  ra¬ 
tionale  for  the  explicit  Platform  Assurance  (APT)  class,  the 
overall  approach  is  to  define  platform  components  in  terms 
of  specification  instead  of  identification.  This  is  to  address 
the  long-standing  problem  that  specific  hardware  compo¬ 
nents  identified  in  a  TOE’s  evaluated  configuration  become 
obsolete  during  or  immediately  after  the  TOE’s  evaluation. 


5.8.1  Platform  Definition  (APT  PDF) 

This  family  requires  a  description  of  the  platform  in  terms 
of  platform  components  that  can  be  obtained  and  assembled 
by  the  end  users.  The  Platform  Definition  Document  (PDD) 
must  include  the  assembly  rules  and  information  about  the 
types,  interfaces  and  security  properties  of  the  components 
to  support  component-specific  security  analysis  against  the 
SFRs.  The  CC  component  leveling  for  this  family  is  deter¬ 
mined  based  on  the  details  provided  in  the  PDD.  For  high 
robustness,  the  SKPP  mandates  the  highest  level,  i.e.,  the 
PDD  must  include  precise  component  interface  specifica¬ 
tions  for  all  platform  components  in  addition  to  the  platform 
component  security  analysis.  The  evaluator  is  also  required, 
at  the  highest  level,  to  verify  a  subset  of  the  interface  specifi¬ 
cations  to  ensure  that  they  provide  adequate  information  on 
component  compatibility.  Based  on  the  MR  CIM  guidance 
that  “the  level  of  detail  of  design  documentation  and  the 
implementation  representation  is  dependent  upon  a  compo¬ 
nent’s  role  in  security  policy  enforcement,”  we  propose  to 
relax  both  of  these  content  and  evaluator  requirements  for 
medium  robustness  separation  kernels.  Specifically,  the  re¬ 
quired  details  of  the  component  interface  specifications  can 
be  less  rigorous,  i.e.,  interface  specifications  are  only  re¬ 
quired  for  components  that  directly  affect  the  implemen¬ 
tation  of  the  policy  enforcement  SFRs,  and  the  evaluator 
will  not  be  required  to  verify  the  interface  specifications  for 
compatibility  information. 


5.8.2  Platform  Specification  (APT_PSP) 

This  family  levies  requirements  on  the  vendor-supplied 
specifications  of  the  interfaces  provided  by  the  platform 
components.  These  specifications  are  necessary  to  support 
functional  analysis  and  vulnerability  assessment  of  the  TSF. 
Three  CC  component  levels  are  defined  for  this  family.  The 
highest  level,  as  specified  in  the  SKPP,  requires  complete 
specifications  of  all  platform  interfaces  (i.e.,  external,  inter¬ 
nal  and  unused  internal  interfaces).  The  middle  level  only 
requires  a  complete  specification  of  the  external  platform 
interfaces  while  the  basic  level  simply  requires  the  identifi¬ 
cation  of  the  external  interfaces.  For  medium  robustness, 
it  is  sufficient  to  downgrade  to  the  middle  level  because 
a  complete  specification  of  the  external  interfaces  can  fa¬ 
cilitate  a  critical  examination  of  the  hardware  functionality 
that  is  externally  visible  to  the  TOE  software  which,  in  turn, 
can  help  support  the  analysis  for  design  correctness  and  ex¬ 
ploitable  vulnerabilities  of  the  TSF. 

5.8.3  Platform  Conformance  Testing  (APT_PCT) 

Regarding  hardware  testing,  the  SKPP  makes  a  distinction 
between  testing  at  the  platform  component  interface  and 
testing  at  the  TSFI  interface.  This  family  addresses  the  lat¬ 
ter  whose  goal  is  to  ensure  that  the  platform  components 
identified  in  the  PDD  function  as  expected  by  the  TSF  soft¬ 
ware.  Testing  at  the  component  interface  level  is  covered  in 
the  AP'I’  PST  family  described  below.  The  CC  component 
leveling  of  this  family  is  based  on  the  scope  and  rigor  of  the 
required  tests.  To  satisfy  the  basic  level,  the  TOE  developer 
is  only  required  to  demonstrate  that  the  components  provide 
the  functional  features  required  by  a  valid  hardware  plat¬ 
form.  The  middle  and  highest  levels,  on  the  other  hand,  fo¬ 
cus  more  on  exercising  the  security  features  provided  by  the 
components.  The  middle  level  requires  testing  of  only  the 
security  features  upon  which  the  TSF  depends.  The  highest 
level  requires  testing  of  all  security  features  that  are  relied 
upon  by  the  TSF  as  well  as  other  hardware  components. 
Since  exhaustive  test  coverage  is  not  required  for  medium 
robustness,  it  is  logical  to  use  the  middle  level  for  medium 
robustness  separation  kernels. 

5.8.4  Platform  Security  Testing  (APT  PSD 

This  family  defines  requirements  for  security  testing  of 
hardware  components  to  be  performed  at  the  component  in¬ 
terface  level.  As  noted  in  its  rationale,  “the  intent  of  this 
class  is  to  make  deterministic  tests  of  the  platform  mecha¬ 
nism  rather  than  relying  on  test  coverage  arguments  at  the 
TSFI  level.”  The  shift  in  the  testing  focus  places  a  stronger 
emphasis  on  security  assessment  to  determine  how  well  the 
components  satisfy  the  SFRs.  Two  CC  component  levels 
are  defined  for  this  class.  Only  external  platform  interfaces 


are  required  for  the  basic  level  while  all  external  and  inter¬ 
nal  interfaces  are  required  for  the  second  level.  Naturally, 
the  SKPP  utilizes  the  second  level.  Since  it  is  anticipated 
that  a  thorough  testing  of  the  platform  mechanisms  that  are 
externally  visible  can  provide  enough  evidence  that  the  ex¬ 
ternal  platform  interfaces  function  correctly  and  can  mod¬ 
erately  resist  attacks,  it  seems  appropriate  to  levy  the  basic 
level  requirements  on  a  medium  robustness  separation  ker¬ 
nel 

5.8.5  Platform  Vulnerability  Assessment  (APT  PVA) 

This  family  complements  the  AVAJVLA  family  by  requir¬ 
ing  that  hardware  vulnerability  assessment  be  considered 
as  part  of  the  software  vulnerability  analysis.  Similar  to 
Apt _PST,  the  difference  between  the  two  CC  component 
levels  defined  is  based  on  the  type  of  platform  interfaces  in¬ 
volved  in  the  assessment,  i.e.,  only  external  interface  (basic 
level)  versus  both  external  and  internal  interfaces  (second 
level).  The  same  argument  used  in  the  APT_PST  also  ap¬ 
plies  here  and  thus,  the  basic  level  prevails. 

5.9  Tests 

The  ATE  class  contains  the  assurance  families:  Analy¬ 
sis  of  Coverage  (COV),  Depth  of  Testing  (DPT),  Functional 
Testing  (FUN),  and  Independent  Testing  (IND).  In  each  of 
these  families  the  medium-robustness  separation  kernel  re¬ 
quirements  adopt  those  of  the  MR  CIM. 

5.10  Vulnerability  Assessment 

The  AVA  class  contains  the  assurance  families:  Covert 
Channel  Analysis  (CCA),  Misuse  (FLR),  Strength  of  Func¬ 
tion  (SOF),  and  Vulnerability  Analysis  (VLA). 

5.10.1  Covert  Channel  Analysis  (AVA  CCA) 

For  the  CCA  family  the  SKPP  specifies  an  explicit  compo¬ 
nent  AVA_CCA_EXP.2,  based  on  AVA_  CCA.2,  but  limited 
to  cover  only  inter-partition  covert  channels.  One  would 
expect  that  the  covert  channel  analysis  requirement  for  MR 
would  cover  only  inter-partition  covert  channels,  whatever 
the  level  of  rigor  of  the  search. 

The  MR  CIM,  on  the  other  hand,  has  a  different  ex¬ 
plicit  component  AVA_CCA_(EXP).2,  that  requires  system¬ 
atic  covert  channel  analysis  of  the  cryptographic  module 
only.  It  contains  an  application  note  that  explains  that  the 
TSF  interfaces  are  not  covered  because  it  is  “considered 
beyond  the  scope  of  effort  and  cost  considered  reasonable 
for  COTS  medium-robustness  products.”  It  goes  on  to  ac¬ 
knowledge  that  this  does  increase  risk. 


Experience  has  shown  that  it  is  likely  that  the  exercise  of 
conducting  a  covert  channel  search,  even  one  that  is  not  sys¬ 
tematic,  may  expose  channels  that  can  and  should  be  miti¬ 
gated,  and  can  yield  valuable  information  about  the  TOE  to 
be  captured  in  guidance  documentation. 

In  applying  the  MR  CIM  rationale  to  the  medium¬ 
robustness  separation  kernel,  it  is  clear  that  that  the  MR 
CIM  requirement  for  systematic  covert  channel  analysis  of 
the  cryptographic  module  does  not  apply  because  the  sepa¬ 
ration  kernel  provides  no  cryptographic  services.  But  there 
are  a  few  issues  particularly  relevant  to  separation  kernels. 

The  purpose  of  a  separation  kernel  is  to  control  informa¬ 
tion  flow;  any  other  function  is  arguably  incidental.  Per¬ 
haps  special  consideration  for  separation  kernels  is  needed. 
Even  at  medium-robustness,  some  covert  channel  analysis 
would  be  beneficial,  such  as  the  informal  search  specified 
by  AVA  CCA.l,  which  normally  comes  into  play  in  the 
Common  Criteria  EAL  5  package. 

For  the  medium-robustness  separation  kernel,  the 
covert  channel  search  could  be  limited  to  inter-partition 
information  flow  policy,  thus  creating  an  explicit  com¬ 
ponent  AVA_CCA_EXP.  1  analogous  to  the  SKPP’s 
AVA_CCAJEXP2. 

5.10.2  Misuse  (AVAJMSU) 

For  MSU  the  SKPP  follows  the  EAL  6  component  and  the 
MR  CIM  follows  the  EAL  4  component.  For  medium¬ 
robustness  separation  kernels,  the  component  specified 
by  the  MR  CIM,  AVA  MSU. 2  Validation  of  Analysis  is 
adopted. 

5.10.3  Strength  of  Function  (AVA_SOF) 

The  Common  Criteria  defines  only  one  component  for  the 
SOF  family.  The  SKPP  and  the  MR  CIM  both  adopt 
AVA_SOF.l,  as  does  this  study.  As  noted  in  the  SKPP, 
these  AVA_SOF  requirements  are  only  applicable  to  the  ad¬ 
ditional  security  requirements  defined  in  the  Security  Target 
for  which  a  claim  of  strength  of  function  is  appropriate. 

5.10.4  Vulnerability  Analysis  (AVA  VLA) 

For  the  VLA  family  the  SKPP  creates  an  explicit  require¬ 
ment  that  modifies  AVAJVLA.4  only  in  the  evaluator  ac¬ 
tions:  it  requires  that  an  NSA  evaluator  conduct  indepen¬ 
dent  vulnerability  analysis  and  penetration  testing  not  build¬ 
ing  on  developer  vulnerability  analysis. 

The  MR  CIM  elevates  the  VLA  requirement 
AVAJVLA. 2,  specified  by  the  EAL  4  package,  to 
AVA_VLA.3  Moderately  Resistant,  which  requires 
that  the  vulnerability  search  be  demonstrably  systematic. 
This  is  what  we  adopt  for  the  MR  SK. 


6  “Catch-22”  Challenges 
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The  absence  of  a  validated  PP  for  medium-robustness 
separation  kernels  poses  a  challenge  for  developers. 
The  Common  Criteria  Evaluation  and  Validation  Scheme 
(CCEVS)  Robustness  FAQ  responds  to  the  question,  “can 
a  TOE/ST  claim  a  robustness  level  without  conforming  to 
a  PP?”  with  the  answer,  “For  Medium  or  High  Robustness, 
this  would  be  theoretically  possible  if  there  were  an  ST  Re¬ 
view  Board  (analogous  to  the  PP  Review  Board)  that  would 
review  the  ST  to  ensure  that  it  adheres  to  the  rules  set  forth 
in  the  Consistency  Instruction  Manuals.  There  currently  is 
no  such  group,  so  there  is  no  way  to  claim  a  Medium  or 
High  Robustness  level  without  claiming  conformance  to  a 
PP.”  Likewise,  the  IAG  position  also  refers  to  a  security 
target,  which  it  says  should  conform  to  a  currently  non¬ 
existent  protection  profile.  Further,  the  position  that  a  pro¬ 
tection  profile  acceptable  to  NSA  must  be  a  “U.S.  Govern¬ 
ment  Protection  Profile,”  and  that  such  a  PP  can  be  devel¬ 
oped  only  by  NSA,  leads  to  an  effective  impasse  for  devel¬ 
opers.  The  upshot  of  this  dilemma  is  that  either  a  proper 
protection  profile  needs  to  be  developed  by  NSA,  or  a  non- 
NSA  produced  PP  would  need  to  be  endorsed  by  NSA. 

7  Summary  and  Conclusions 

We  have  presented  security  functional  and  assurance 
requirements  for  a  medium-robustness  separation  kernel. 
Rather  than  performing  a  deep  protection  profile-style  anal¬ 
ysis  of  security  environment  and  objectives,  we  drew  upon 
the  SKPP  and  guidance  documents  to  interpolate  the  re¬ 
quirements  informally,  following  a  methodology  that  may 
serve  as  an  example  for  future  efforts  to  interpolate  medium 
robustness  requirements  corresponding  to  future  high  ro¬ 
bustness  PPs. 

The  SKPP  differs  in  important  ways  from  the  standard 
EAL  6  package.  This  is  due  to  special  factors  that  arise  for  a 
separation  kernel  qua  separation  kernel.  These  factors  must 
also  be  given  consideration  when  determining  the  require¬ 
ments  for  a  MR  SK.  Consequently,  the  MR  SK  assurance 
components  do  not  follow  the  MR  CIM  in  every  detail,  but 
in  some  cases  follow  the  pattern  of  the  SKPP  instead. 

Although  our  results  are  not  intended  to  replace  a 
medium-robustness  separation  kernel  protection  profile, 
they  do  provide  a  step  in  that  direction.  They  adopt  vir¬ 
tually  all  of  the  SKPP  functional  requirements  and  have 
met  or  exceeded  all  of  the  MR-CIM  (and  EAL  4)  assurance 
requirements,  on  a  few  items  equalling  the  SKPP  require¬ 
ments.  Absent  a  protection  profile,  the  requirements  pre¬ 
sented  herein  constitute  a  conservative  basis  for  proceeding 
with  medium-robustness  separation  kernel  development. 
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